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Abstract 

NASA’s Superfluid Helium On-Orbit Transfer (SHOOT) project is a Shuttle-based 
experiment designed to acquire data on the properties of superfluid helium in 
micro-gravity. Aft Flight Deck Computer Software for the SHOOT experiment is 
comprised of several monitoring programs which give the astronaut crew 
visibility into SHOOT systems and a rule based system which will provide 
process control, diagnosis and error recovery for a helium transfer without 
ground intervention. Given present Shuttle manifests, this software will 

become the first expert system to be used in space. The SHOOT Command and 
Monitoring System (CMS) software will provide a near real time highly 
interactive interface for the SHOOT principal investigator to control the 
experiment and to analyze and display its telemetry. The CMS software is 
targeted for all phases of the SHOOT project: hardware development, pre-flight 
pad servicing, in-flight operations, and post-flight data analysis. 


Introduction 


The SHOOT experiment is a demonstration of the critical technology required to service 

cryogenically cooled satellites in a micro-gravity environment. Superfluid helium has a 

number of unusual properties including zero viscosity, very high thermal conductivity, 

and a thermo-mechanical effect in which the helium is "attracted" to heat. The experiment 

will be controlled continuously during a four to seven day mission by a scientist at a 

Payload Operations and Control Center (POCC) or by an astronaut on the Aft Flight Deck 

(AFD) of the shuttle orbiter. Mission objectives for SHOOT include demonstrating the 
transfer of superfluid helium between two dewars, verifying the design of a superfluid 
helium transfer line and man rated fluid coupler, demonstrating a technique called heat 

pulse mass gauging to very accurately determine the amount of helium present and the 
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onboard control of a helium transfer without ground intervention. All of these are 
necessary for the future development of NASA's Superfluid Helium Tanker (SFHT) which 
will NASA’s next generation of astrophysical observatories in low earth orbit (i.e., SIRTF, 
AXAF, ASTROMAG). 

Some of these objectives are best accomplished by an expert operator from the POCC, others 
must be accomplished by a shuttle crewman having real time visibility and control of SHOOT 
systems. As a result, the operations and control software has been divided into two separate 
and distinct parts. Each has its own capabilities tailored for the environment, specific 
operations, and level of expertise of the operator. POCC software is designed to preserve the 
maximum operational flexibility for an expert operator during all phases of SHOOT 
hardware use including pre, post and in-flight experiments. AFD software is designed to 
provide a non-expert shuttle crewmember with the specific information and control 
functions for a given experiment phase. Diagnostics and error handling are provided for 
off nominal conditions. 


Experiment Overview 

The SHOOT experiment consists of a series of transfers between two dewars in the shuttle 
cargo-bay. Each dewar (Figure 1.) is heavily instrumented with temperature, pressure and 
fluid level sensing devices. Operators at the POCC can select individual devices to read and 
display through commands sent to the SHOOT electronics on the shuttle (Figure 2.). Data that 
is received at the POCC is converted to meaningful units, limit checked and archived in real 
time. In this way the experiment control computer at the POCC is the experiment Pi's 
interface to the flight hardware. Most operations are performed under POCC control. 



Figure 1. The SHOOT dewar and cryostat 
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Figure 2. Block Diagram of the SHOOT Electronics 

Legend: C&DH-Command and Data Handling Unit, HLVS-Heater, Level Detector 

Valve Driver System, TPMS-Temperature and Pressure Measurement System, 
CCGSE-Customer Carrier Ground Support Equipment, EIP-Experiment Interface 
Panel 


Certain operations require testing the ability of the SHOOT Fluid Acquisition apparatus to 
pump helium during normal orbiter attitude maintenance maneuvers. Since the SFHT will 
be shuttle based verifying this capability is of prime importance to achieving the SHOOT 
science objectives. This involves real-time, graphical feedback to the crew during Reaction 

Control System jet firings. The crew will initiate the firing during a helium transfer and 

observe the system performance in real time. Upon observation of a loss of flow condition 

the acceleration is to be terminated and the ability of the flow to restart observed. Other 

operations such as the Beneficial Acceleration Settling and the Extra-Vehicular Activity 
(EVA) Monitoring function are also best performed onboard. Monitoring programs specific 
to these functions will be provided for the crew's use. 
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Figure 3. Matrix showing the division of control between the ground and crew 


The SFHT will contain many thousands of liters of helium if it is to meet the requirements of 
large space based observatories. Fluid transfer rates up to 1000 liters per hour are 
conceivable. Even at this flow rate a satellite resupply is a multi-hour process. The objective 
of the AFD expert system is to demonstrate the ability to control a helium transfer operation 
autonomously from orbit without crew or ground intervention. 


Aft Flight Deck Software 

Four programs are being developed to support SHOOT science objectives from the Aft Flight 
Deck. Three of these are for monitoring only, while the fourth will demonstrate the 

autonomous control of cryogen transfer in space without ground intervention. 

AFDex (Yaf-dek\) is a rule-based system under development at the NASA Ames Research 

Center for the SHOOT experiment, which will operate on the Space Shuttle's Aft Flight Deck 
(AFD) computer. The primary goal of AFDex is to provide intelligent process control, 

diagnosis, and error recovery capabilities for the transfer of superfluid helium between 
two dewars in the orbiter’s cargo bay. During a nominal transfer, AFDex is responsible for 
sending commands which control the payload, monitoring telemetry from the payload, and 
providing a graphical display which reflects the current state of the dewars and the 
transfer. In the event of an abnormal condition, AFDex must diagnose the condition and 

formulate plans for error recovery. Diagnosis is associative (based upon relationships 
between symptoms and causes) as opposed to a model-based approach which would be too 
inefficient for this application. 
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Figure 4. Display of AFDex during Precool Phase 


Although the system is designed to automate the transfer operation, AFDex has facilities to 
interact with the astronauts. Data which is relevant to a current operation is displayed 

graphically. An astronaut may guide the system’s behavior (i.e. select an error recovery 

strategy) via menus and input fields. Input is asynchronous and preemptable. Asynchrony 
allows the system to continue reasoning about events while interacting with the user. 
Preemptability allows the system to interrupt a current interaction in response to some 
event. 

AFDex receives data via a serial connection through the Hitchhiker carrier's avionics. 

Since the system must respond in real-time to to events represented in this data stream, a 
number of mechanisms have been developed to reduce the effort of processing payload 

data. The system may be viewed as consisting of three components: the payload avionics, a 
telemetry preprocessor, and the rule-based system. At the lowest level, AFDex may 

command the avionics hardware to control what data it receives from the payload and at 
what rate. This provides a coarse-grained, low overhead filter suitable for specific 

operations although it has limited flexibility and nontrivial operational complexity. 

Once telemetry is received by the Aft Flight Deck computer from the payload avionics, a 
preprocessor is used to focus attention on certain classes of data (to the exclusion of 

others) from which it will create facts to assert into the expert system knowledge base. The 
behavior of this preprocessor is dynamically controlled by the expert system. In an effort 

to reduce the overhead of processing large amounts of invariant data, the preprocessor may 
be commanded to report only relevant changes in data values. Additional preprocessing 
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may include qualitative analysis (i.e. from 23 degrees to warm), constraint demons (alert if 
GRT-12 and GRT-35 are the same temperature), and deviation from anticipated (simulated) 
values. Data from the preprocessor is asserted into a Rete network [Forgy] which 

efficiently handles pattern matching and rule invocation. Within the expert system a 
number of strategies (modalities, prioritized agenda, rule partitioning, etc.) are used to 
focus attention and respond efficiently to events. 

AFDex is being developed in CLIPS (a derivative of OPS-5 and ART developed by NASA) and C 
for delivery on a 386-based GRiD 1530 laptop computer. The current system has knowledge 
concerning command generation and receipt, valve devices, germanium resistance 

thermometers, all operations required for nominal transfer, and simulation of certain 
error modes for each device. This is captured in a knowledge-base currently consisting of 
84 rules and 114 initial facts. The capabilities and size of the system will increase 
significantly as development continues. 

SHOOT utilizes three additional programs on the Aft Flight Deck computer. These programs 
provide real-time monitoring capabilities during specific SHOOT operations. Currently 

these programs have no commanding capability and thus are dependent upon ground 
control. We are currently evaluating the option of embedding these programs within rule- 

based systems similar to AFDex. This would allow certain mission objectives to be achieved 
in the event of an extended loss of ground communication. 

Knowledge-based process control and diagnosis has proved effective in the development of 
AFDex. A rule-based approach provides a natural framework to develop a system in which 
multiple threads of execution are inherent. There are potentially many actions possible at 
any time, and each action may be only slightly related to any other action. Diagnosis is 

unobtrusively interleaved with control. Rules provide an excellent mechanism for 
applying large amounts of very specific knowledge in response to changes in the 
environment. CLIPS has proved to be a fast, compact, and portable system which is able to 
represent this knowledge and apply it in real-time. This is complemented by the 

availability of all source code which allows CLIPS to be customized and embedded in an 
arbitrary application. More significantly, AFDex demonstrates that expert systems have 

become a mature technology which is being integrated into aerospace operations. 


Shoot Ground Based Command and Monitoring System 
Design 

The goal in designing the SHOOT Command and Monitoring System (CMS) software was to 
create a system that is easy to use as possible while retaining full control of the experiment 
at a low level for maximum flexibility. Because the SHOOT experiment is highly interactive 
and will be controlled for extended periods of time, a good user interface is very important. 
The Macintosh’s icon based point-and-click environment provides quick and easy methods 
for performing complicated tasks. 

The user interface of the CMS was fully prototyped before any coding was done and drove 
the design of the software using a top down approach. Windows were designed from the 

user’s perspective (a specialist in cryogenics) to perform each function required. 

Flexibility will allow the software to be reusable for all aspects of the experiment including 

early tests with the hardware, system level integration, servicing the experiment while in 

the payload bay of the shuttle on the launch pad, and operations during and after flight. 
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Should the CMS become overloaded it is designed to degrade gracefully. Every function in 
the system has a certain priority; lower priority operations will be gradually phased out 
until higher priority operations have time to catch up. (Figure 5.) 
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Figure 5. Prototype CMS display showing telemetry, command and status 
windows 


Implementation 

The SHOOT Command and Monitoring System is being developed on a Macintosh II using the 
Macintosh Programmers Workshop (MPW) Toolset and is being written in C. The event 
oriented operating system on the Macintosh enables simultaneous user interaction and 
internal processing to occur without having multiple processes. 

Priority is highest for archiving and calibrating telemetry, followed by commanding 
operations and updating the display. Two identical systems will be used during flight at the 
POCC for redundancy, each capable of performing everything required to conduct the 
experiment. Only one system will be allowed to up-link commands at a time. The other 
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system may be used for more time consuming tasks such as trend analysis of old data or 
plotting new data as it arrives in real time. 

The software is logically broken down into modules corresponding to functionality. 
Telemetry processing consists of buffering the data as it comes in through the serial port, 
decommutating a data packet, performing conversions of raw data into engineering units, 
and archiving both raw and converted data to disk (Figure 6.). The user is notified if any 
telemetry indicates an error condition. 



Figure 6. Functional diagram of the ground based CMS software 


Command processing consists of a portion of the user interface to construct command 
packets and a command assembler which formats the packet for up-link and sends it out the 
serial port. Commanding can be automated for repetitive operations and a macro facility 
exists to simplify the creation of a packet. 

Display processing is responsible for updating the screen and for changing display 
attributes. The telemetry being displayed is disjoint from telemetry processing so that old 
data may be viewed even if it is not present in the current down-link packet, new data is not 
necessarily being displayed, although it is still being checked for error conditions and 
archived. The display for a specific device is updated as new corresponding data comes in. 
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Each device may be individually selected for numerical display and a subset of all devices is 
always displayed graphically. Alerts and other error conditions are made known to the user 
in both the telemetry display window and a separate alert window. In addition an audible 
bell may sound if desired. 

The user interface also allows general configuration of the system as well as facilities for 
performing utility functions such as heat pulse mass gauging or integrating the flow rate. 

The development of the SHOOT Command and Monitoring System on a widely available and 
easy to use system, the Macintosh II, is proving to be both cost effective and efficient. The 
most important features are the point-and-click interface for interactive control and the 
reusable nature of the software. 


Conclusions 

A knowledge-based approach facilitates the use of complex hardware by novice user. Point- 
and-click interfaces provide an expert user with powerful, intuitive, and flexible control 
over the same hardware. SHOOT represents the incorporation of these mature technologies 
into aerospace operations. 

Superfluid Helium On-Orbit Transfer is a NASA Office of Space Flight Advanced Program 
Development Branch sponsored flight experiment managed by the Goddard Space Flight 
Center Cryogenics Technology Branch of the Engineering Directorate. The Ames Research 
Center Artificial Intelligence Research Branch of the Information Sciences Directorate is 
supporting GSFC by developing the software. 


References 

Forgy, C.L. "On the Efficient Implementation of Production Systems", Ph.D. dissertation, 
Camegie-Mellon University, 1974 


